Решение для виртуализации сетей VMware NSX-T, в отличие от его vSphere-версии NSX-V, не имеет графического интерфейса для настройки отсылки логов на серверы Syslog.

Graham Smith написал краткую заметку о настройке Syslog для решения VMware NSX-T, включая NSX-T Manager, узлы Edge Nodes и серверы ESXi.

Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware Log Insight. Сначала заходим по SSH на NSX-T Manager и выполняем там следующую команду, указав IP-адрес сервера Log Insight:

MulNSXT01> set logging-server 192.168.10.8 proto udp level info 
        WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.

На узлах Edge Nodes также нужно выполнить такую же команду, зайдя по SSH:

DCA-MulNSXT-ESG01> set logging-server 192.168.10.8 proto udp level info
        WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.

На серверах ESXi процесс выглядит несколько иначе. Нужно выполнить вот такую последовательность команд:

[root@DCA-MulComp01:~] esxcli network firewall ruleset set -r syslog -e true
[root@DCA-MulComp01:~] esxcli system syslog config set --loghost=udp://192.168.10.8:514
[root@DCA-MulComp01:~] esxcli system syslog reload
[root@DCA-MulComp01:~] esxcli system syslog mark -s "This is a test message"

Первая команда разрешает в фаерволе трафик Syslog, вторая - настраивает сервер адрес сервера, третья - подхватывает настройки, ну а четвертая - отсылает тестовое сообщение, чтобы можно было проверить работоспособность механизма Syslog со стороны Log Insight.

Там это тестовое сообщение можно увидеть в разделе Events:

Чтобы проверить логирование на стороне фаервола, можно создать простое правило с тестовым тэгом:

Далее в Log Insight можно увидеть это событие, поискав по этому тегу:

Чтобы проверить конфигурацию Syslog на стороне сервера ESXi, нужно выполнить следующую команду:

[root@DCA-MulComp01:~] esxcli system syslog config get
   Check Certificate Revocation: false
   Default Network Retry Timeout: 180
   Dropped Log File Rotation Size: 100
   Dropped Log File Rotations: 10
   Enforce SSLCertificates: true
   Local Log Output: /scratch/log
   Local Log Output Is Configured: false
   Local Log Output Is Persistent: true
   Local Logging Default Rotation Size: 1024
   Local Logging Default Rotations: 8
   Log To Unique Subdirectory: false
   Message Queue Drop Mark: 90
   Remote Host: udp://192.168.10.8:514
   Strict X509Compliance: false

На стороне NSX-T Manager и на узлах Edge Nodes конфигурацию Syslog можно проверить такой командой:

DCA-MulNSXT-ESG01> get logging-servers 
Mon Dec 28 2020 UTC 17:37:16.600
192.168.10.8:514 proto udp level info

Большинство администраторов, которым требуется управление виртуальной инфраструктурой VMware vSphere с помощью сценариев используют интерфейс VMware PowerCLI, который является оберткой движка PowerShell. Это требует наличие отдельного хоста, с которого идет исполнение сценариев, а также часто требуются такие сервисы, как vRealize Orchestrator и vRealize Automation.

Поэтому, начиная с VMware vSphere 6.7, появился новый Open Source интерфейс для управления виртуальной средой - Script Runtime Service (SRS). Он представляет собой Kubernetes-приложение для управления инстансами PowerCLI и вызова командлетов через REST API.

Интерфейс SRS позволит интегрировать управление исполнением сценариев PowerCLI в vSphere Client для виртуальных машин и приложений.

SRS создает отдельное пространство имен в кластере Kubernetes, которое позволяет PowerCLI работать как Kubernetes pod. Этот легковесный PowerCLI pod реализуется как образ контейнера, который имеет все модули PowerCLI и требует только необходимые управляющие компоненты, трансформирующие ввод и вывод для сценариев, а также управляющие исполнением запрошенного сценария.

Первоначальная инсталляция SRS запускает задачу Kubernetes, которая регистрирует SRS в сервисах провайдера идентификации vSphere SSO. Единожды аутентифицированные клиенты SRS API автоматически включаются в список доверенных на серверах vCenter.

Надо отметить, что сейчас SRS находится еще в ранней стадии разработки и не работает с vSphere with Tanzu (поэтому не развертывайте его со службами Supervisor Cluster).

Попробовать работу с движком SRS можно двумя путями:

1. Устанавливаете SRS в кластере Kubernetes на любую из машин (инструкции здесь)

2. Устанавливаете SRS на специальным образом подготовленную виртуальную машину на базе Photon OS (инструкции тут).

Начать экспериментировать с SRS API можно, перейдя по ссылке:

https://{SRS-IP}/swagger/index.html

SRS использует механизм vCenter Server SSO для идентификации и аутентификации. У любого пользователя с доступом через SSO есть возможность настроить PowerCLI-соединения к серверам vCenter Servers. Как начать это делать описано вот тут.

SRS работает с vSphere 6.7 и более поздними версиями. Сообщить о проблемах вы можете вот тут, а также присодинившись к VMware Code и каналу в Slack.

На днях компания VMware выпустила обновление своего пакета vRealize Operations Management Pack for Kubernetes 1.5.1, которое позволяет отслеживать состояние контейнерных сред Kubernetes из консоли Operations. Напомним, что ранее оно называлось Management Pack for Container Monitoring.

Надо отметить, что vRealize Operations с помощью данного пакета может обеспечивать мониторинг как сред Tanzu Kubernetes в публичном или онпремизном облаке, так и инфраструктуры OpenStack с развернутыми кластерами Kubernetes.

Давайте посмотрим, что появилось нового в MP for Kubernetes 1.5.1:

1. Поддержка vRealize Operations Advanced

Теперь пользователи издания Advanced также могут использовать пакет управления, ранее эта возможность была доступна только владельцам лицензий Enterprise. Для vRealize Operations Cloud поддержка также сохранилась.

2. Улучшенный сбор метрик средствами Prometheus

Многие пользователи сред Kubernetes используют Prometheus для сбора метрик в кластерах. Теперь vRealize Operations за счет MP может запрашивать метрики с сервера Prometheus, а данные об инфраструктуре получать напрямую через Kubelet API.

Такая интеграция по-прежнему позволит вам использовать механизмы интеллектуального анализа данных, в том числе Troubleshooting Workbench и Metric Correlation.

Prometheus хранит данные в отличном от vRealize Operations формате. Чтобы преобразовать и получить данные для метрик Prometheus можно использовать следующих экспортеров (exporters):

• Telegraf Kubernetes Input Plugin
• cAdvisor Exporter
• cStats Exporter
• Kube-State-Metrics
• Windows-node-exporter
• Node Exporter

Если ваша команда разработки дорабатывает какие-то метрики в экспортерах, то они автоматически становятся доступны в vRealize Operations.

vRealize Operations также собирает метки (labels) с серверов Prometheus. Они могут включать важные данные, такие как IP-адреса узлов, имена приложений или процессов, номера версий или даже, например, какие метрики используются для конкретного ядра CPU:

Для игнорирования ненужных метрик (например, GUID) можно использовать фильтры:

3. Мониторинг приложений в Kubernetes

Теперь интеграция vRealize Operations и Prometheus позволяет более глубоко взглянуть на уровень приложений:

В данном примере показано приложение Redis, для которого используется экспортер Telegraf. Для него vRealize Operations может видеть такие метрики как: число клиентов, как много времени CPU требуется на выполнение вызовов, информацию о памяти и application backlogs.

4. Поддержка новых Tanzu Mission Control API

Теперь vRealize Operations и MP могут не только автоматически мониторить облачные среды Tanzu Mission Control на платформе AWS, но и полностью поддерживают обновленный API. Также недавно было анонсировано, что Tanzu Mission Control будет поддерживать Tanzu Kubernetes Grid on vSphere 7, и вскоре эта поддержка будет добавлена и в Management Pack.

Скачать VMware vRealize Operations Management Pack for Kubernetes 1.5.1 можно по этой ссылке. Документация находится здесь.

Компания Veeam, производитель лидирующих на рынке средств для обеспечения доступности виртуальных датацентров, в декабре объявила о доступности для скачивания новой версии Veeam Backup for Microsoft Office 365 v5. Напомним, что с помощью этого решения можно производить резервное копирование и восстановление данных Office 365 из облака, а также бэкапить локальные данные Microsoft Exchange, OneDrive и Sharepoint.

Давайте посмотрим, что нового появилось в этом решении:

1. Поддержка Microsoft Teams

Многие Enterprise-администраторы используют Microsoft Teams для создания среды совместной работы для команд различного размера в рамках предприятия. Теперь Veeam Backup for Microsoft Office 365 v5 позволяет производить резервное копирование этих сред с использованием специального API от Microsoft.

Этот API позволяет узнать, с каким каналом ассоциирован каждый data point, что позволяет организовать бесшовное резервное копирование и восстановление сред Microsoft Teams для SharePoint Online, Exchange и OneDrive.

Veeam Explorer for Microsoft Teams включает в себя возможности восстановления для каналов, настроек, прав доступа, приложений и вкладок, включая данные и компоненты.

Также появилась возможность поиска по 17 полям:

2. Улучшения производительности

Теперь объекты SharePoint обрабатываются параллельно для каждого сайта, что существенно ускоряет процесс бэкапа. Также одна инсталляция бэкап-сервера может обрабатывать до 5 раз больше прокси, что увеличивает возможности по управлению бэкапом больших инфраструктур. При этом прокси не обязательно должны быть в том же или трастовом домене.

Кроме того, теперь данные Office 365 в два раза быстрее перемещаются между локальной БД и объектным хранилищем репозиториев.

3. Обновление Restful API

Помимо поддержки Microsoft Teams, появились функции отчетности о ежемесячном использовании ресурсов, что позволяет гибко использовать эту информацию в целях биллинга (она поставляется в виде JSON). Через API теперь также можно управлять лицензиями пользователей.

Скачать можно по этой ссылке. Также Veeam выпустила целую книжку "Microsoft Teams Backup", в которой описаны лучшие практики по резервному копированию таких пользовательских сред.

Как многие администраторы уже знают, 31 декабря этого года прекращается официальная поддержка технологии Adobe Flash большинством браузеров. Это в первую очередь затрагивает VMware vSphere Web Client, использовавшийся для управления старыми версиями VMware vSphere, когда новая платформа vSphere Client на базе HTML5 еще только развивалась (сейчас это полнофункциональный клиент, а старого веб-клиента больше нет). Напомним, что ранее была прекращена поддержка Internet Explorer.

Вот список продуктов и их версий, которые затронет отсутствие поддержки Flash со стороны браузеров:

В июне этого года, в связи с большим числом заявок от крупных компаний, было решено сделать Workaround для Flash Player. Чтобы включить его для отдельных URL, нужно внести изменения в файл mms.cfg, где следует добавить следующие строчки:

EOLUninstallDisable=1

EnabledAllowList=1

AllowListPreview=1

AllowListUrlPattern=https://FQDN/

Вместо FQDN нужно указать адрес вашего сервера vCenter, vCloud Director или веб-консоли другого продукта.

Вот где находится файл mms.cfg в зависимости от браузера и операционной системы:

Более подробно об этом рассказано в KB 78589.

Это гостевой пост нашего партнера, сервис-провайдера ИТ-ГРАД, предоставляющего услуги аренды виртуальных машин из облака. Уже в начале шестидесятых портфолио IBM насчитывало десятки различных систем. Каждое новое поколение разительно отличалось от предыдущего. Покупатели рвали на себе волосы в тщетных попытках поспеть за всеми инновациями и требованиями нового железа...

В прошлом году мы писали о полезной утилите VMware Configuration Maximums Tool, которая позволяет выводить максимальные конфигурации для различных продуктов VMware. Эта очень полезная штука для администраторов vSphere умеет не только выводить список всех максимумов, но и сравнивать их для разных версий одного продукта.

Для этого нужно выбрать пункт меню "Compare Limits" и указать сравниваемые версии продуктов:

Штука эта очень удобная, но у нее есть большой недостаток - она выводит все конфигурации максимумов (для NSX-T, например, их 274 штуки, поэтому сложно отследить, что именно изменилось).

Поэтому Dale Coghlan написал интересный PowerCLI-модуль VMware.CfgMax, который решает эту проблему - в режиме командной строки можно узнать об изменениях максимумов, а также сделать еще несколько полезных вещей.

После установки модуля можно вывести список доступных продуктов, которые есть на configmax.vmware.com:

Для конкретного продукта можно вывести список его версий/релизов:

Также для конкретной версии можно вывести список категорий максимумов:

С помощью командлета можно вывести все максимумы для конкретного продукта и определенной его версии:

Можно вывести все конфигурации в рамках заданной категории:

Ну и, наконец, с помощью командлета Compare-CfgMaxLimits можно сравнить максимумы конфигураций для разных версий одного продукта:

Как вы видите, тут есть поле CompareStatus, которое и говорит нам, новая ли эта настройка (New), измененная по сравнению с прошлым релизом (Modified), нетронутая (пусто) или удаленная (Deleted) в новой версии.

С помощью параметра New можно, например, вывести все новые настройки:

Параметр Modified выведет только отличающиеся максимумы конфигураций:

Ну а параметр Deleted выведет устаревшие настройки:

Ну и все вместе, без неизмененных значений:

Очень удобная штука, все это также можно экспортировать в формат CSV и сравнивать в Excel. Для этого можно использовать следующую команду:

PS > $product = Get-CfgMaxProduct -Name 'NSX-T Data Center'
PS > $releaseA =  $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.0.0'
PS > $releaseB =  $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.1.0'
PS > Compare-CfgMaxLimits -Product $product -Release $releaseA -CompareRelease $releaseB | Export-Csv -Path compare-status.csv -NoTypeInformation

Скачать данный PowerCLI сценарий с примерами вы можете по этой ссылке.

На днях на сайте проекта VMware Labs появилось очередное интересное обновление - новая версия гипервизора VMware ESXi Arm Edition 1.2 для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства).

Напомним, что о версии ESXi Arm Edition 1.1 мы писали вот тут, а здесь также рассказывали об установке этого гипервизора на платформу Raspberry Pi.

Давайте посмотрим, что нового в VMware ESXi Arm Edition 1.2:

• Если у хоста нет датасторов, то datastore browsing отключен
• Пофикшен отсутствующий параметр context_id для вызовов CPU_ON
• Исправлена проблема с контроллером GICv2 (теперь SGI всегда включены и работают как устройства GIC-500)
• Поддержка гостевых ОС на базе big-endian
• Убраны требования/ограничения на initrd для ВМ без UEFI

В целом, все это технические фиксы - но обновить вашу тестовую лабу не помешает. Новая версия ESXi Arm встает только как свежая установка, обновление прошлых версий не поддерживается. Можно сохранить прошлые тома VMFS, выбрав опцию "Preserve VMFS", но машины надо будет перерегистрировать заново.

Скачать ESXi Arm Edition 1.2 можно по этой ссылке.

На днях один из сотрудников компании VMware сделал аддон Helm Chart под решение vRealize LogInsight Cloud, который позволяет обрабатывать логи кластеров Kubernetes в среде VMware vSphere и TKG (Tanzu Kubernetes Grid).

Работает это решение в двух средах:

• Интегрированные кластеры Tanzu Kubernetes Grid (TKG) K8
• Отдельные инсталляции кластеров K8 на платформах vSphere/AWS

После установки аддона вы можете начать собирать метрики с кластеров TKG и K8 в вашем окружении, а также визуализовывать их на дашбордах наподобие вот такого:

Вообще Helm - это менеджер пакетов для Kubernetes. Это один из лучших путей поиска, шаринга и использования программного обеспечения в кластерах K8. Helm Charts это YAML-манифесты Kubernetes, объединенные в один пакет, который можно развернуть в среде K8. После запаковки установка Helm Chart в кластере производится одной командой helm, которая позволяет просто указать параметры развертывания и апгрейда.

Перед использованием данного средства вам понадобятся:

• Токен для vRealize LogInsight Cloud API
• Helm версии 3.x
• Административный доступ к кластеру Kubernetes

Итак, процедура по шагам:

1. Добавляем репозиторий Chart:

helm repo add loginsight-cloud https://munishpalmakhija.github.io/loginsight-cloud-helm/

2. Получаем файл с переменными из рабочей директории:

helm show values loginsight-cloud/loginsight-cloud-helm > values.yaml

3. Обновляем параметры API Token и другие настройки, специфичные для вашей среды. Начинаем с команды:

cat values.yaml

4. Устанавливаем компонент Chart:

helm install test-vrlic loginsight-cloud/loginsight-cloud-helm -f values.yaml

5. Верифицируем узлы Kubernetes Pods:

kubectl get pods -A | grep test-vrlic

6. Верифицируем релиз Helm:

helm list

Второй рабочий процесс установки (интерактивный режим):

1. Добавляем репозиторий Chart:

helm repo add loginsight-cloud https://munishpalmakhija.github.io/loginsight-cloud-helm/

2. Устанавливаем Chart в интерактивном режиме:

helm install test-vrlic loginsight-cloud/loginsight-cloud-helm --set vrlic.apikey=SETME --set tag.environment=DEMO

3. Верифицируем узлы Kubernetes Pods:

kubectl get pods -A | grep test-vrlic

4. Верифицируем релиз Helm:

helm list

После установки проверяем, что логи идут к LogInsight, это должно выглядеть следующим образом:

Чтобы начать пользоваться пробной бесплатной версией облака vRealize LogInsight Cloud, можно запросить триальную версию тут.

Многие администраторы уже используют продукт VMware vSAN 7 Update 1 для создания отказоустойчивых кластеров хранилищ на базе серверов ESXi. Некоторое время назад мы писали про технологию Cloud Native Storage (CNS), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

Давайте посмотрим, что нового появилось в возможностях CNS в обновлении vSAN 7 U1:

1. Расширение томов PersistentVolumeClaim

В Kubernetes v1.11 появились функции расширения томов за счет изменения объекта PersistentVolumeClaim (пока только офлайн). Помните, что уменьшение тома (shrink) не поддерживается.

2. Статический провижининг в Supervisor Cluster

Эта возможность позволяет презентовать существующий том в кластере K8s, который будет интегрирован с vSphere Hypervisor Cluster (он же Supervisor Cluster, vSphere with K8s, Project Pacific).

3. Поддержка vVols для vSphere K8s и TKG Service

Теперь обеспечивается поддержка внешних хранилищ на базе vK8s и TKG с использованием томов vVols.

4. Функции Data Protection for Modern Applications

В vSphere 7.0 U1 появились функции поддержки резервного копирования Dell PowerProtect и Velero для Pacific Supervisor и TKG кластеров. Для Velero вы можете инициировать создание снапшотов через Velero plugin и хранить их в облаке S3.

5. Функции vSAN Direct

Возможность vSAN Direct позволяет использовать Direct Attach Storage (обычно на базе физических HDD-дисков) для хранения виртуальных машин VMware vSphere.

Вы можете создавать vSAN Direct Datastores, которые не являются общими для кластера датасторами, но физические диски таких хранилищ можно, например, напрямую подключать к виртуальным модулям (Virtual Appliances) или к контейнерам, исполняемым в среде vSphere, которым нужно объектное хранилище, но при этом хочется использовать его напрямую, минуя стандартный путь данных vSAN.

На сайте virten.net (клевый, кстати, ресурс) появилось описание серьезной ошибки файловой системы VMware VMFS 6, которая используется для создания датасторов в ESXi 7.0 (Build 15843807) и 7.0b (Build 16324942). Он касается кучи ФС (VMFS heap), которая переполняется из-за некорректной работы механизма ее очистки. В VMware vSphere 7 Update 1 эта ситуация решена. Сама проблема описана в KB 80188.

Симптомы переполнения кучи, как правило, следующие:

• Датасторы на хостах показывают статус "Not consumed"
• Виртуальные машины не могут выполнить vMotion
• Виртуальные машины "сиротеют" (переходят в статус "orphaned") при выключении
• При создании снапшота возникает ошибка "An error occurred while saving the snapshot: Error."

В логе vmkernel.log могут появляться следующие сообщения об ошибках:

• Heap vmfs3 already at its maximum size. Cannot expand
• Heap vmfs3: Maximum allowed growth (#) too small for size (#)
• Failed to initialize VMFS distributed locking on volume #: Out of memory
• Failed to get object 28 type 1 uuid # FD 0 gen 0: Out of memory

Память для кучи VMFS принудительно очищается при аллокации ресурсов файловой системы, например, обычных thick-дисков. Поэтому воркэраунд получается следующий - нужно создать диск Eager zeroed thick на всех смонтированных к хостам ESXi датасторах. Делается это командой:

# vmkfstools -c 10M -d eagerzeroedthick /vmfs/volumes/datastore/eztDisk

Удалить этот диск можно командой:

# vmkfstools -U /vmfs/volumes/datastore/eztDisk

Проблема только в том, что нужно выполнить эту операцию на каждом датасторе каждого хоста. Поэтому есть вот такая команда для всех датасторов и хостов:

# for I in $(esxcli storage filesystem list |grep 'VMFS-6' |awk '{print $1}'); do vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk;echo "Removing disk $I/eztDisk"; vmkfstools -U $I/eztDisk; done

Результат будет примерно таким:

Сейчас какого-то отдельного патча для решения этой проблемы нет, поэтому нужно самостоятельно следить за поведением инфраструктуры. Основным симптомом является появление в vmkernel.log следующего сообщения:

Maximum allowed growth * too small for size

Если у вас есть такой продукт, как VMware Log Insight, то вы можете настроить аларм на появление этого сообщения в логе.

На сайте проекта core.vmware.com появился интересный документ из будущего, описывающий особенности проектирования и сайзинга кластеров хранилищ vSAN, актуализированный 4 декабря этого года - VMware vSAN 7 Update 1 Design Guide:

На самом деле, документ этот очень полезен для администраторов VMware vSAN, планирующих развертывание корпоративной инфраструктуры хранилищ на базе серверов ESXi. В нем рассматриваются все новые возможности версии vSAN 7 Update 1, включая технологию HCI Mesh, которая позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов):

Основные разделы документа:

• vSAN Design Overview
• vSAN Limits
• Network Design Considerations
• Storage Design Considerations
• VM Storage Policy Design Considerations
• Host Design Considerations
• Cluster Design Considerations
• Determining if a Workload is Suitable for vSAN
• Sizing Examples
• vSAN Sizing Tool
• VMware vSAN GSS Support

Очень полезная вещь - это наличие рекомендаций и лучших практик по различным аспектам проектирования кластров:

Интересная табличка по рекомендациям выставления опций по реакции на событие изоляции (Isolation Responce / Isolation Policy):

Интересны также указания на часто встречающиеся ошибки проектирования:

В общем, документ мегаполезный. Скачать VMware vSAN 7 Update 1 Design Guide можно вот тут.

Многие из вас знают про лучшее на рынке программно-аппаратное решение для организации хранилищ под виртуализацию StarWind Virtual SAN. О прошлом его обновлении, которое вышло весной этого года, мы писали вот тут.

Недавно компания StarWind выпустила обновление этого продукта в виде виртуального модуля OVF на базе Linux для VMware vSphere - VSAN OVF Version 20201027 Version 8 (build 13861).

Давайте посмотрим, что там появилось нового:

Общие улучшения и багофиксы

• Обновлено ядро модуля Linux Kernel.
• Настройка iScsiPingCmdSendCmdTimeoutInSec теперь по умолчанию выставлена в 5 секунд.
• Исправленный процесс логирования для оповещений по email, теперь они не смешиваются с общими событиями почтового сервера.
• Улучшены операции по остановке службы (ранее этот процесс мог подвиснуть в определенных обстоятельствах).
• Обновлена имплементация SCSI-протокола для более корректного процессинга команд UNMAP/TRIM.

Улучшения синхронной репликации

• Добавлена опция использования SMB-шары как ресурса witness для устройств с синхронной репликацией.
• Исправлена обработка персистентных резерваций для устройств с синхронной репликацией.
• Исправлены некоторые случаи обновления состояния партнерского узла после восстановления из ситуации split-brain.

Управляющая консоль (Management Console)

• Исправлено падение консоли, когда StarWind Event log содержал записи с некорректными строковыми значениями.
• Обновлен диалог настроек нотификаций по email (добавлена валидация и спрятаны поля логина-пароля при отсутствии необходимости аутентификации).

Модуль StarWindX PowerShell

• Добавлена возможность добавления HA-устройств в конфигурации Node Majority. Теперь узел StarWind или SMB-шара могут быть использованы как witness. Более подробно об этом можно узнать из примеров сценариев CreateHAPartnerWitness.ps1 и CreateHASmbWitness.ps1.

• Поправлена обработка параметра ALUA для командлетов по созданию HA-устройства.

Скачать пробную версию StarWind Virtual SAN для VMware vSphere в формате виртуального модуля OVF можно по этой прямой ссылке.

На сайте проекта VMware Labs появилась очень замороченная, но интересная штука для гиков - симулятор Storage Simulator Using Cellular Automata.

Это такая утилита, построенная на принципах клеточного автомата (cellular automata, CA), которая позволяет смоделировать характеристики производительности для путей данных в кластере vSAN. Сам методика клеточных автоматов позволяет смоделировать и исследовать комплексную систему со множеством элементов, работающих параллельно и имеющих короткие соединения между собой, при этом создающих эмерждентную сущность.

При симуляции стека хранилищ данная утилита моделирует передачу блоков данных по сети через аппаратные ресурсы по различным коротким соединениям, таким как CPU->кэш->DRAM->SSD/HDD, соединения PCIe, Ethernet и т.п. Вот небольшое видео о том, как это работает:

Основная цель такой симуляции - получить идеальные показатели пиковой пропускной способности к хранилищам - так называемая speed-of-light (SOL) throughput.

При моделировании запросов ввода-вывода на чтение-запись применяются различные модели движения блоков данных по сети. Эти модели включают в себя функции репликации данных, вычисление parity, контрольных сумм, шифрование, компрессия данных и некоторые другие факторы, влияющие на длительность операций.

Результаты можно использовать для бенчмаркинга реальных инфраструктур, изменения настроек для повышения производительности, а также понимания затыков (bottlenecks), понижающих общую производительность стека работы с хранилищами vSAN в виртуальной инфраструктуре.

Вот пример такого моделирования:

В общем, если у вас есть время на подобные игры - скачивайте Storage Simulator Using Cellular Automata по этой ссылке. Инструкции по использованию доступны там же на вкладке "Instructions".

Пару недель назад на сайте проекта VMware Labs вышли обновления сразу нескольких утилит, поэтому вы, возможно, пропустили апдейты HCIBench 2.5 и 2.5.1. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.4 мы писали вот тут.

Давайте посмотрим, что нового появилось в версиях 2.5 и 2.5.1:

• Добавлена возможность тестирования в рамках топологии vSAN HCI Mesh, теперь можно добавлять локальные и удаленные датасторы vSAN одновременно.
• Добавлена поддержка локальных хранилищ, включая VMFS и тестирование vSAN-Direct.
• Новый режим vSAN Debug Mode, который позволяет автоматически собрать бандлы vm-support и vmkstats при тестировании vSAN.
• Изменена конвенция имен виртуальных машин на {vm_prefix}-{datastore_id}-batch_num-sequence_num.
• Улучшенный формат отчета о тестировании.
• Возможность указывать кастомные IP для тестовых машин.
• Возможность выставлять CPU и память для тестовых машин.
• Добавлено руководство по сетевому траблшутингу как раздел пользовательской документации.
• Возможность обновления на текущую и последующие версии одной командой:
  tdnf install -y git && git clone https://github.com/cwei44/HCIBench.git && sh HCIBench/upgrade.sh
MD5 Checksum: 1d14426f92b353e90469a8623ade2bc1 HCIBench_2.5.1.ova
• Исправлены ошибки с тестированием не-vSAN кластера, а также с превалидацией политики хранилищ.
• Прочие исправления ошибок.

Скачать VMware HCIBench 2.5.1 можно по этой ссылке.

На сайте проекта VMware Labs появилось очередное обновление - утилита Horizon Peripherals Intelligence, предназначенная для самодиагностики периферийных устройств пользователями решения VMware Horizon. C помощью данного средства можно проверить работоспособность и поддержку устройств как со стороны конечных пользователей, так и администраторов платформы Horizon.

На данный момент поддерживаются следующие устройства:

• USB-хранилища
• USB-принтеры
• USB-сканеры
• Камеры

В будущем будут также добавлены новые виды устройств. Сама же утилита Horizon Peripherals Intelligence служит для решения следующих задач:

• Публикация отчета о диагностике устройств по запросу конечных пользователей. Сам отчет доступен админам и пользователям на веб-портале, а из него будет понятны проблемы использования устройств. В отчете будут содержаться рекомендации, на базе которых администраторы смогут предпринять определенные действия по исправлению ситуации.

• Обслуживать спектр пользовательских устройств в рамках поддерживаемых со стороны официального списка совместимости device compatibility matrix. Пользовательские окружения разные (версия ОС, версия агента и т.п.) - поэтому этот момент сложно отслеживать вручную. По запросу пользователя выводится отчет о поддерживаемых устройствах в его окружении.

• Для администратора предоставляется возможность получить доступ к метаданным устройств в каждой категории, где он может загружать, изменять и удалять метаданные, таким образом обслуживая матрицу поддерживаемых устройств на машинах пользователей.

Для начала работы вам потребуется:

• VMware Horizon 7.x или более поздняя версия
• Client OS - Windows 10
• Agent OS - Windows 10, 2016, 2019
• Виртуальный модуль построен на базе VMware Photon OS 3.0, что требует ESXi 6.5 или более поздней версии

Скачать Horizon Peripherals Intelligence можно по этой ссылке.

На сайте проекта VMware Labs появилась очередная полезная штука - Storage Performance Tester. С помощью данного средства администраторы VMware vSphere могут в один клик проверить производительность хранилищ в плане IOPS, Latency и циклов CPU на одну операцию ввода-вывода для серверов VMware ESXi.

Эта утилита автоматизирует все шаги, которые необходимо предпринять для тестирования, включая развертывание виртуальных машин, запуск нагрузки по вводу-выводу, а также анализ производительности хранилища. Метрики, полученные в результате тестирования, визуализируются на графиках. Единственная вещь, которую вам нужно сделать - это выполнить соответствующую команду и ждать сгенерированного отчета о производительности хоста ESXi.

Средство создано как для администраторов платформы vSphere, так и для разработчиков, которым требуется решать проблемы производительности в виртуальной инфраструктуре. Также Storage Performance Tester удобно использовать для получения максимальных параметров производительности аппаратного обеспечения, а также программных компонентов (драйверы, настройки vSphere и vSAN).

Для запуска тестовой среды вам понадобятся:

• python3
• sshpass
• 2 ГБ свободного места
• Linux-окружения (с версией ядра не менее 2.6.31)

Вот небольшое обзорное видео, где можно посмотреть всю процедуру запуска утилиты и, собственно, сам отчет с результатами тестирования:

Скачать Storage Performance Tester можно по этой ссылке.

Какое-то время назад мы писали о первой версии платформы виртуализации VMware ESXi для архитектуры процессоров ARM, которая получила название ESXi-Arm или ESXi Arm Edition. Также мы рассказывали об установке этой платформы на компьютер Raspberry Pi на базе процессора ARM.

Недавно на сайте проекта VMware Labs появилось обновление этой платформы до версии 1.1. Эту версию нужно обязательно ставить заново, потому что обновление с версии 1.0 не поддерживется.

Давайте посмотрим, что там появилось нового:

• Исправлена критическая ошибка, вызывавшая розовый экран смерти (PSOD) при добавлении к коммутатору VDS (см. тут)
• Поддержка аппаратной платформы Arm N1 SDP
• Поддержка виртуальных машин на процессорах Neoverse N1 CPU
• Улучшения стабильности работы на платформах LS1046A и LX2160A
• Исправления ошибок для отображения некорректного использования CPU на vCenter/DRS
• Исправление ошибки с аварийным завершением виртуальной машины при полной заполненности хранилища
• Исправление ошибки с поддержка устройств non-coherent DMA
• Теперь можно ставить гипервизор имея в распоряжении 4% от 4 ГБ памяти вместо 3.125 (критично для некоторых аппаратных платформ)
• Улучшения работы с последовательным портом
• Обновление документации (больше информации об iSCSI, документы по платформам LS1046ARDB и Arm N1SDP, обновлен список поддерживаемых гостевых ОС)

Скачать VMware ESXi Arm Edition 1.1 можно по этой ссылке. Ну и бонусом несколько видео от Вильяма Лама по использованию этой платформы:

Многие из вас знакомы с одноплатной ARM-архитектурой компьютеров Raspberry Pi, которые позволяют модульно собирать очень крутые штуки для целей тестирования и обучения. Недавно компания VMware выкатила технологическое превью гипервизора ESXi для процессоров ARM (он же ESXi-Arm), которое доступно на сайте VMware Labs.

Конечно же, многие пользователи бросились устанавливать его на компьютеры Raspberry Pi, которые в большом количестве есть у энтузиастов. Оказалось, что поставить туда ESXi весьма простая задача, особенно, если речь идет о Raspberry Pi 4.

Коллеги с блога VirtualG поставили ESXi на Raspberry Pi 4 Model B (можно использовать модель с 4 ГБ или 8 ГБ памяти):

• 1x SD card (память)
• 2x USB drive (один для записи гипервизора, а второй как installation media)
• Кабель USB-C (питание)
• Micro HDMI для монитора

Сначала лучше прочитать официальный гайд по продукту, который есть на странице ESXi-Arm сайта VMware Labs. Для старых модификаций Raspberry Pi могут быть нюансы, но с новыми для Windows порядок примерно такой:

1. Скачиваем последнее firmware
2. Скачиваем последнее community firmware
3. Форматируем SD-карту как FAT32
4. Получаем из скачанного firmware-master.zip
5. Удаляем все 4 образа kernel WinImage
6. Копируем содержимое загрузочной директории на SD-карту
7. Копируем содержимое архива RPi4_UEFI_Firmware_v1.20.zip с перезаписью поверх существующего содержимого на SD-карту
8. Если у вас Raspberry Pi на 4 ГБ, открывайте config.txt и добавляйте следующую строчку в конец файла без пробелов: gpu_mem=16

Настраиваем UEFI:

• Вставляем SD-карту в Raspberry Pi
• Подключаем USB-клавиатуру и монитор по HDMI
• Подключаем питание через USB-C
• Нажимаем ESC до того, как покажется UEFI menu
• Идем в раздел:
  • Device Manager > Raspberry Pi Configuration > Advanced Configuration
• Подсвечиваем опцию Limit RAM to 3GB
• Нажимаем Enter и стрелками на клавиатуре выставляем значение DISABLED
• По F10 сохраняем конфигурацию
• Нажимаем ESC, чтобы выйти на домашнюю страницу
• Идем к Continue и нажимаем Enter

Тепреь загружаем установочный образ VMware-VMvisor-Installer-7.0.0-16966451.aarch64.iso по этой ссылке.

Теперь из ISO-образа с помощью UNetbootin надо создать загрузочную флешку:

Далее:

• Вставляем установщик на USB-флешке в Raspberry Pi
• Нажимаем ESC до того, как покажется UEFI menu
• Выбираем USB-флешку первой в порядке загрузки

После начала загрузки ESXi:

• Быстро нажимаем SHIFT+O (это буква)
• Внизу экрана вбиваем autoPartitionOSDataSize=8192 (это ограничит установку ESXi 8 ГБ, остальное пространство можно будет отдать под датастор для виртуальных машин)
• При установке ESXi убедитесь, что указано корректное устройство для установки гипервизора
• Вставляем сетевой кабель и убираем флешку

После этого ваш ESXi загрузится и получит IP-адрес от DHCP, который лучше заменить на статический. После этого вы можете соединиться с хостом через веб-интерфейс и увидеть, что для остатков пространства на флешке был создан датастор для виртуальных машин.

Вот, собственно, и все. Также вы можете почитать еще одну интересную статью про установку ESXi на Raspberry Pi.

Wolfgang Taitl в своем блоге обратил внимание на серьезную проблему, касающуюся некоторых NFS-хранилищ и процесса создания резервных копий виртуальных машин на VMware ESXi. Это известная проблема.

Суть ее заключается в том, что при удалении снапшота ВМ, по завершении ее резервного копирования, она замирает примерно на 30 секунд, не принимая никакой ввод-вывод. Происходит это на некоторых NFS-хранилищах, в частности HPE SimpliVity. В итоге - приложения, чувствительные ко времени, работают плохо, ну и в целом такое поведение не очень приятно для производственных систем.

Проблема проявилась при использовании платформы VMware vSphere 6.7, текущей версии Veeam Backup and Replication и хранилища HPE SimpliVity, которое поддерживает презентацию томов только в режиме NFS v3.

При этом в такой же комбинации продуктов, но на блочных хранилищах удаление снапшота занимало 1-2 секунды.

После общения с поддержкой нашлись следующие workaround'ы, которые не подошли:

• Использовать NFS v4 вместо v3 (доступно не на всех хранилищах)
• Использовать другой транспорт (transport mode), например, Direct access или NBD (Network Block Device). Но Direct access доступен не всегда, а NBD - медленный режим.
• Можно использовать режим hot-add с виртуальным модулем backup appliance, но тогда он должен быть на каждом хосте (см. KB 201095).
• Можно отключить синхронизацию времени с хостом для ВМ с приложениями, которые страдают из-за замирания времени в гостевой ОС. Об этом можно почитать в KB 1189. Но это так себе решение.

На текущий момент получается, что это проблема именно VMware ESXi, см. статью KB 2010953. Также она описана и в базе знаний Veeam - KB 1681 (там же указаны и обходные пути). Таким образом, выходит, что в некоторых случаях ни одно из решений не подходит на 100%.

У компании VMware есть отличное решение Log Insight, которое предназначено для поиска любых данных в виртуальной инфраструктуре, анализа лог-файлов и визуализации аналитики. На прошедшем VMworld Online 2020 была представлена версия Log Insight 8.2.

Если вы администратор VMware vSphere, то наверняка имели необходимость заглядывать в лог vmware.log, который находится в папке с виртуальной машиной, для поиска некоторых событий и решения проблем с данной ВМ. Там могут находиться события reconfiguration events, миграции vMotion, сообщения VMware tools, memory state, события power on/off, включаемые фичи, API-запросы и многое другое.

Все эти сообщения можно отправлять в реальном времени для мониторинга со стороны VMware vRealize Log Insight и отлавливания их с помощью алертов по заданным параметрам. Делается это с помощью возможностей Interactive Analytics.

Файл vmware.log находится в папке с виртуальной машиной и имеет некоторую ротацию:

Чтобы посылать данные лога в Log Insight, нужно изменить Configuration Parameters для ВМ. Для этого сначала выключаем ее, идем по правой кнопке в Edit settings в vSphere Client, выбираем вкладку VM Options и кликаем Edit Configuration:

Далее нужно нажать Add Configuration Params:

После этого добавляем параметр vmx.log.syslogID со значением <vmname>_vmx_log, где vmname - это имя виртуальной машины. Этот айди будет передаваться в Log Insight:

Далее включаем виртуальную машину и на вкладке Interactive Analytics в Log Insight видим, что машина генерирует больше 2000 событий, у этих событий есть типы:

Далее мы можем сформировать запрос на поиск того или иного события и сделать из него алерт с определенным действием (например, отправить webhook или в Operations Manager).

В данном случае происходит отправка письма администратору:

Чтобы отключить логирование, нужно просто удалить значение из поля vmx.log.syslogID:

Пару недель назад компания VMware анонсировала обновление своей платформы Cloud Director 10.2, предназначенной для создания интегрированной среды сервис-провайдеров, предоставляющих виртуальные машины в аренду своим клиентам. Напомним, что о прошлой версии vCD 10.1 мы писали в мае этого года вот здесь.

Ну а на прошедшем VMworld новым возможностям была посвящена сессия HCPS2407 (по этому тексту ее и нужно искать тут):

Давайте посмотрим, что появилось нового в vCD 10.2. Основные области нововведений представлены на картинке:

1. Единая инфраструктура для гибридной среды

Компания VMware делает ставку на то, что крупные компании будут строить гибридные инфраструктуры из собственных площадок и ресурсов сервис-провайдеров, поэтому теперь VMware Cloud Director on-premises и службы VMware Cloud Director в VMware Cloud on AWS имеют единую базу кода, то есть представляют собой один базовый продукт.

Соответственно, и администраторы, и клиенты облака могут управлять инфраструктурой в любом облаке, действуя в единой гибридной среде в рамках предоставленных полномочий.

2. Глобальная доступность VMware Cloud Director 

В четвертом квартале 2020 года ожидается, что службы VMware Cloud Director будут доступны по всему миру, включая наш с вами регион EMEA. При этом администраторы смогут управлять инстансами в разных регионах, если будет выполнено основное условие по latency<150 миллисекунд между площадками.

3. Улучшенная интеграция NSX-T со службами Network & Security

NSX-T в связке с Cloud Director будет предоставлять следующие возможности в облачной инфраструктуре:

• Поддержка распределенного сетевого экрана L4-7 и расширенных функций, таких как VRF lite.
• Улучшения интерфейса, которые позволят растягивать сеть между несколькими виртуальными датацентрами на разных площадках, что позволит применять политики распределенного фаервола к гибридным окружениям.
• Сети клиентов от собственного датацентра к сервис-провайдеру можно будет соединить по layer 2 VPN, вне зависимости от онпремизной версии NSX (NSX-V или NSX-T).
• NSX Advanced Load Balancer (он же Avi Networks Load Balancer) заменит нативный балансировщик NSX-T Load Balancer в издании NSX-DC Base Edition. Это также даст такие возможности, как WAF, DNS, SSL Termination, rate-limiting и другие в решении NSX ALB Enterprise edition.

4. Улучшения в поддержке Kubernetes

В этой сфере появится два основных нововведения:

• Службы Containers as a Service with Tanzu - теперь в Cloud Director будет интегрировано решение VMware vSphere with VMware Tanzu, что позволит сервис-провайдерам производить оркестрацию кластеров K8s прямо из нативных средств управления vSphere и vCD. Для развертывания контейнерных сред можно будет использовать Container Service Extension 3.0, который дает функции по управлению жизненным циклом всех типов кластеров через Cloud Director Cluster API, CLI и Container Service Extension-CLI, а также плагин в графическом интерфейсе.
• Новое средство Cloud Director App Launchpad 2.0, которое позволит клиентам облаков использовать приложения и не думать о нижележащей инфраструктуре. Сервис-провайдеры смогут предложить маркетплейс для пользователей, где они смогут выбрать приложения (на базе контейнеров или виртуальных машин). Вторая версия лончпада поддерживает Container Service Extension 3.0, что позволит пользователям запускать приложения в инфраструктуре Org VDC или кластере K8s автоматически. Будут поддерживаться и кастомные приложения, а также будет реализована тесная интеграция с VMware Cloud Marketplace, что позволит, например, автоматически синхронизировать приложения с выходом их новых версий.

5. Упрощенные функции развертывания Cloud Director

Теперь vCD будет развертываться с помощью переработанного мастера, а также производить внутреннюю проверку на ошибки. Также будет проверяться ввод пользовательских данных и проводиться автоматические бэкапы при установке.

6. Улучшения гибкости и повышение эффективности хранилищ

• Cloud Director 10.2 будет интегрирован с конфигурациями vSphere Storage Policy-based IOPS, что позволит настраивать Storage I/O Control для ресурсов Storage I/O на базе отдельных ВМ из административного интерфейса
• Можно будет использовать shared disks для кластеров Microsoft и Oracle, а также персистентных томов.
• Object Storage Extension (OSE) 2.0 будут позволять клиентам управлять их сервисом AWS S3 через OSE.
• Также OSE 2.0 будет предоставлять поддержку Cloudian 7.2 и Dell ECS 3.4.
• В портале для клиентов будет множество улучшений (например, Guided Tours для обращения внимания на предлагаемые сервисы и фичи), нотификаторы для разных ситуаций (Advisories), а также функции поиска Quick Search.

7. Расширенное предоставление информации клиентам об их облаках

Приложение для клиентов vRealize Operations Tenant App 2.5 будет улучшено в самых разных аспектах, включая поддержку Container Service Extension Kubernetes Clusters, что позволит получать больше информации о приложениях в контейнерах. Также будут предоставлены широкие возможности по созданию и кастомизации отчетов об инфраструктуре. Кроме того, можно будет кастомизировать email-оповещения для клиентов с учетом их потребностей.

Доступность VMware Cloud Director 10.2 ожидается до конца четвертого квартала этого года, следите за новостями.

На сайте проекта VMware Labs недавно появилось средство для администраторов архитектуры VCF и контейнеров - Sample Data Platform on VMware Cloud Foundation with VMware Tanzu for Kubernetes Provisioning.

Несмотря на замудреное название, утилита Sample Data Platform предназначена для простой вещи - дать пользователям VMware Cloud Foundation 4.0 возможность получить платформу оперирования данными для гостевого кластера Tanzu Kubernetes Grid менее, чем за 20 минут, на примере сервисов Kafka, Spark, Solr и ELK.

Также в состав утилиты входит пример финансового приложения (с использованием реальных данных dxFeed), которое показывает, как все компоненты этого решения работают вместе.

С помощью утилиты можно выполнить 4 шага по созданию Data Platform:

• Развертывание компонентов платформы Kafka, Spark, Solr и ELK за 20 минут.
• Kafka Publisher - получение данных финансового рынка из публичного источника dxfeed.
• Spark Subscriber - подписаться на данные рынка из топиков Kafka, обработка данных и их запись в Solr
• Logstash Subscriber - подписаться на данные рынка из топиков Kafka и запись их в Elasticsearch через logstash, а также создание дэшборда kibana.

Более подробно о том, как выполняются все эти шаги можно посмотреть в видео ниже:

Скачать Sample Data Platform on VMware Cloud Foundation with VMware Tanzu for Kubernetes Provisioning можно по этой ссылке.

Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Одним из лидеров отрасли является решение StarWind Virtual SAN, у которого есть множество функций хранения, обеспечения доступности и защиты данных. А сегодня мы поговорим еще об одном бизнесе компании StarWind - программно аппаратных комплексах для специальных задач...

Недавно мы писали об анонсе Project Monterey на прошедшей конференции VMworld Online 2020. Это переработка архитектуры VCF таким образом, чтобы появилась родная интеграция новых аппаратных возможностей и программных компонентов. Например, новая аппаратная технология SmartNIC позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF. Но на этом новости не закончились.

На днях VMware выпустила еще одно важное средство на сайте проекта VMware Labs - модуль ESXi-Arm. Это, по-сути, издание VMware ESXi для компьютеров с 64-битными процессорами архитектуры ARM. Пока, конечно же, в режиме технологического превью, созданного в целях сбора обратной связи от пользователей.

История проекта такова - группа инженеров внутри VMware решила портировать ESXi с архитектуры x86 на ARM, после чего энтузиасты внутри компании поддерживали согласование нововведений в гипервизоре в рамках платформы x86 с версией для ARM. Теперь эта версия ESXi считается доведенной до ума, и она была выпущена публично:

На данный момент в экспериментальном режиме было протестировано следующее оборудование:

• Datacenter:
• Avantek Workstation (Ampere eMAG)
• Avantek Server (Ampere eMAG)
• Lenovo ThinkSystem HR330A (Ampere eMAG)
• Lenovo ThinkSystem HR350A (Ampere eMAG)
• Near Edge:
• SolidRun Honeycomb LX2
• Far Edge:
• Raspberry Pi 4b - 4GB or 8GB Model (8 ГБ очень рекомендуется, также для ESXi/VMFS очень желательно использовать USB 3.0)
• LS1046A-based NXP Freeway

Вы также можете управлять таким ESXi на архитектуре ARM с помощью обычного VMware vCenter 7.0 или более поздней версии.

Скачать VMware ESXi для ARM в виде загрузочного ISO-образа можно по этой ссылке. Документация доступна там же, правильный документ надо выбрать из комбобокса:

Также вот небольшое обзорное видео об установке ESXi на компьютер Raspberry Pi от Вильяма Лама:

Продолжаем рассказывать об анонсах прошедшей на прошлой неделе конференции VMworld 2020 Online. В прошлый раз мы рассказывали о проекте Project Monterey, который является продолжением развития технологии Project Pacific для контейнеров на базе виртуальной инфраструктуры, а сегодня расскажем о новой сертификации.

Программа VMware Certified Technical Associate (VCTA) предназначена для тех специалистов, которые осуществляют ежедневные операции в виртуальной инфраструктуре. Обучающий курс в рамках данной сертификации затрагивает операции в нескольких облачных окружениях, настройку сети, безопасность и управление устройствами.

Если сравнивать сертификацию VCTA и VMware Certified Professional (VCP), то можно сказать, что первая - это, в основном, для начинающих администраторов, которые только погружаются в тему и отвечают за Day-2 операции, а VCP предполагает понимание всех аспектов виртуальной инфраструктуры, включая ее проектирование, развертывание и настройку.

При этом VCTA не является каким-то обязательным условием сертификации VCP, ее может получить любой желающий. Обучение происходит на портале VMware Customer Connect Learning. Основные треки сертификации VCTA:

• VCTA-DCV – доступно сейчас
• VCTA-NV – доступно сейчас
• VCTA-SEC – доступно сейчас
• VCTA-CMA – скоро будет доступно
• VCTA-DW – в разработке
• VCTA-AM – в разработке

Экзамены можно сдавать в тестовых центрах Pearson или дома через платформу Pearson OnVue, где ведется живой онлайн-мониторинг сдаваемых онлайн экзаменов.

На данный момент о сертификации VCTA есть документ с вопросами и ответами, который дает основные пояснения к программе. Также 27 октября пройдет онлайн-вебинар (регистрация тут), где будут озвучены основные детали новой сертификации.

Какое-то время назад мы писали о новых возможностях недавно вышедшего обновления платформы виртуализации VMware vSphere 7 Update 1. Одним из главных улучшений стало увеличение максимальных параметров платформы, что привело к возможности организовывать кластер HA/DRS из еще большего числа хостов, а на самих хостах - исполнять виртуальные машины еще большего размера.

Данные нововведения можно проиллюстрировать следующей таблицей:

В кластере теперь может быть до 96 хостов, правда не все технологии поддерживают это число. Например, кластер VMware vSAN 7 Update 1 и топология HCI Mesh поддерживают все еще 64 хоста, а технология Native File Services в vSAN 7 U1 поддерживает только 32 хоста.

Самое большое улучшение - теперь в кластере может быть до 10 тысяч виртуальных машин, а это на 50% выше показателя vSphere седьмой версии:

Для виртуальных машин, находящихся под экстремальной нагрузкой, теперь поддерживается 768 виртуальных процессоров (vCPU) и до 24 ТБ памяти. Это больше, чем для виртуальных машин на любой из других облачных или онпремизных платформ:

К подобным нагрузкам можно отнести системы на базе SAP HANA и EPIC Cache Operational Database. Все эти ресурсы виртуальная машина может реально использовать:

Для виртуальной инфраструктуры в целом на базе одного кластера в Sphere 7 Update 1 максимальные показатели следующие: 393 216 vCPU (96 хостов по 4 096 vCPU) / 2.3 ПБ памяти (96 хостов по 24 ТБ):

Если говорить об исполнении контейнеров vSphere with Tanzu в такой инфраструктуре, то их может поместиться просто огромное количество. Согласно статистике, средний размер контейнера составляет 1 vCPU и 400 МБ памяти (например, контейнер node.js "кушает" 1/3 CPU и 384 МБ памяти). Таких контейнеров в одном кластере vSphere 7 U1 может быть запущено 393 216 штук. А контейнеров node.js можно запустить до миллиона экземпляров!

Как многие из вас знают, в последние пару лет очень сильно увеличилось число и масштаб атак, связанных с уязвимостями в аппаратном обеспечении. Наибольшую известность получили уязвимости Meltdown и Spectre, которые были обнаружены в процессорах Intel.

Самый неприятный момент, связанный с подобного рода уязвимостями - это то, что поскольку они связаны с аппаратной частью процессоров на самом низком уровне, то, во-первых, ее сложнее исправить и доставить конечным пользователям, а, во-вторых, неправильное обновление, закрывающее эти дырки, может вызвать различные побочные эффекты.

Так, например, было с производительностью серверов VMware ESXi, когда производители ОС совместно с Intel выпустили соответствующие обновления, а VMware выпустила закрывающий уязвимость патч. Сам патч тогда пришлось отозвать и ждать нового, а ведь это потраченного время администраторов, время пользователей и время, в течение которого существует угроза безопасности инфраструктуры предприятия.

Поэтому производители процессоров, совместно с вендорами платформ виртуализации, сейчас уделяют этому моменту особое внимание. Конечно же, в этом направлении работает и AMD, которая активно внедряет следующие технологии:

• Secure Encrypted Virtualization (SEV) - первая версия технологии, анонсированная в 2016 году. Она позволяет изолировать виртуальные машины от гипервизора, со стороны которого может быть угроза безопасности при его компрометации. Если гипервизор попытается считать память гостевой ОС, он увидит только зашифрованные данные.
• SEV-ES (Encrypted State) - вторая версия технологии, представленная в 2017 году. Она дополняет защиту памяти гостевой ОС шифрованием регистров CPU гостевой ОС. Таким образом, гипервизор не может видеть регистры процессора, активно используемые виртуальной машиной.
• SEV-SNP (Secure Nested Paging) - следующее поколение технологии, которое было анонсировано в этом году. Оно добавляет функции аппаратной безопасности для контроля над интеграцией памяти гостевых ОС, что защищает от таких атак, как data replay, memory re-mapping и других (подробнее тут и на картинке ниже).

Надо начать с того, что у VMware уже есть защита памяти и данных гостевой ОС на уровне платформы (а в самих ОС тоже есть средства защиты памяти и процессора), но, само собой, эти механизмы на надежны на 100%, потому что ключевой компонент платформы - гипервизор, обладает очень широкими полномочиями (в виду необходимости), и при его компрометации ничего особо не поможет. Поэтому самое разумное - это поддержать подход изоляции ВМ от гипервизора на аппаратном уровне. Он, кстати, называется Trusted Execution Environment (TEE).

Подход AMD заключается в том, что они добавляют специальный Secure Processor, маленький сопроцессор, интегрированный в основной чип CPU, который является основой безопасности и поддерживает операции шифрования, в том числе и для SEV-ES.

Первое поколение EPYC CPU поддерживало хранение только 15 ключей шифрования, но следующее поколение уже поддерживает более 500. Один из таких ключей используется для гипервизора, а остальные - для гостевых систем.

Для чего вообще нужно защищать регистры процессора гостевых систем? Очень просто - когда виртуальная машина переключает контекст исполнения (меняет процессор), гипервизор получает ресурсы CPU обратно, вместе с содержимым регистров. А в них может храниться много "полезного" для злоумышленника - например, ключи для расшифровки дисков гостевой системы.

Работает механизм ключей так - гостевая ОС запрашивает у процессора с поддержкой SEV ключ шифрования для памяти, а SEV-ES расширяет его и на регистры процессора тоже, после чего гостевая ОС может безопасно использовать память и регистры, не беспокоясь что гипервизор или другие ВМ, изолированные в рамках процессов VMX, считают их содержимое. Очевидно, что гостевая ОС тоже должна поддерживать реализацию SEV-ES (поэтому надо читать соответствующую документацию к ним, чтобы узнать о поддержке).

Самым большим минусом использования технологии SEV-ES является невозможность поддержки таких техник, как vMotion, Memory Snapshots, Guest Integrity, Hot Add, Suspend & Resume, Fault Tolerance и горячих клонов - ведь для их реализации гипервизор должен иметь прямой доступ к памяти гостевых систем. В то же время надо отметить, что это не ограничение от AMD, которая заявляет, что SEV поддерживает live migration и прочее, а ограничение реализации от VMware.

В большинстве производственных окружений невозможность применения этих технологий будет ограничивать использование SEV-ES только системами, требующих наивысшего уровня защищенности.

С другой стороны, например, недавно вышедшее решение vSphere with Tanzu не использует vMotion для машин с контейнерами виртуализованных приложений - они просто выключаются на одном хосте и включаются на другом, то есть здесь есть перспективы применения SEV-ES.

Также использованием технологии SEV-ES можно управлять в пакетном режиме сразу для нескольких тысяч виртуальных машин через интерфейс PowerCLI, что особенно актуально для контейнеров Tanzu. На данный момент VMware еще не опубликовала официальный референс по командлетам для SEV-ES, ждем.

Ну и недавно VMware выпустила интересное видео, рассказывающее о первой имплементации технологии SEV-ES в платформе VMware vSphere 7 Update 1:

Как итог можно отметить, что пока такие технологии, как Secure Encrypted Virtualization имеют достаточно узкое применение ввиду их ограничений. Однако это лишь первые шаги, которые производители процессоров делают совместно с вендорами платформ виртуализации, чтобы защитить ИТ-среду предприятия он новой волны атак на программно-аппаратную инфраструктуру датацентра. Дальше все это будет развиваться, будет и поддержка AMD SEV-SNP, что уже будет существенно уменьшать поверхность возможных атак.

На этой неделе компания VMware опубликовала новость об окончании поддержки браузера Internet Explorer 11. Шаг этот совершенно логичен, поскольку сама Microsoft анонсировала окончание поддержки Explorer 11 продуктами линейки MS365 (вот официальный guidance). Пользователям предлагается мигрировать на браузер Edge.

Поддержка IE 11 будет прекращена всеми активными версиями vSphere Client, начиная со следующего за vSphere 7.0 Update 1 релиза платформы. На самом деле, де-факто IE 11 был в опале уже довольно давно, и его использует менее 2% пользователей согласно статистике (большинство, конечно же, корпоративные). Одна из причин, помимо качества предоставляемого сервиса (стабильность и производительность) - недостаточная защищенность (смотрим пример от января этого года).

Также IE не поддерживает новые возможности HTML5, не имеет полной поддержки CSS, WebAPI и WebGL. Работает vSphere Client в IE намного хуже, чем в других современных браузерах. Также там возникает много ошибок, работая с которыми VMware тратит много ресурсов.

Таким образом, скоро IE 11 вылетит из списка совместимых браузеров для vSphere Client. Случится это для всех версий с выходом vSphere 7 Update 2. В общем, имейте в виду.

Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1, а также решения для создания отказоустойчивых хранилищ на базе хостов VMware vSAN 7 Update 1. В статье о vSAN мы упоминали о том, что VMware расширяет службы vSAN Native File Services за счет поддержки протокола SMB. Он интегрирован с Microsoft Active Directory и поддерживает аутентификацию Kerberos. Давайте посмотрим на эти возможности подробнее.

Во-первых, начнем с небольшого обзора от Дункана Эппинга:

Поддержка протокола SMB была введена в vSAN не просто так - целью была поддержка постоянных томов read-write many (RWM) volumes для cloud native applications (то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes). Для доступа поддерживаются хранилища SMB версий v2.1, так и v3 (SMB v1 находится в статусе Deprecated).

SMB-хранилища, создаваемые в vSAN, могут быть доступны из Windows-клиентов (версии 8/2012+) и Mac-клиентов (OS 10 и позднее). Это, совместно с поддержкой Active Directory, делает SMB-хранилища отличным вариантом для:

• VDI-сценариев, где пользователи предпочитают перенаправление каталога user/home на выделенную файловую шару.
• Файловые ресурсы, обслуживающие различные топологии (например, удаленные офисы или филиалы), могут управляться напрямую из vSAN, без необходимости иметь отдельную ВМ для предоставления общего доступа к папкам.

Файловые шары видны через Windows MMC, где администраторы могут: 

• Смотреть число клиентских соединений к шаре
• Смотреть число открытых файлов
• Управлять разрешениями и безопасностью (в стиле NTFS)
• Закрывать клиентские соединения
• Закрывать открытые файлы

Как мы писали выше, поддерживается и протокол аутентификации Kerberos, который предотвращает доступ NFS-клиентов через более уязвимые методы доступа, такие как auth_sys. vSAN поддерживает 3 модели аутентификации:

• KRB5, который проводит только безопасную аутентификацию (только на NFS v4.1)
• KRB5I, включая аутентификацию и проверку контрольных сумм
• KRB5P, включая аутентификацию, проверку контрольных сумм и шифрование

Надо отметить, что несмотря на то, что VMware vSphere 7 U1 поддерживает кластеры до 64 хостов, службы Native File Services поддерживают доступ до 32 хостов к файловым шарам.

Теперь службы Skyline Health (ранее это называлось "vSAN Health") содержат дополнительные хэлсчеки, включая file server health и share health:

Тут есть три основных типа проверок:

• Проверки Infrastructure health checks - развернута ли машина FSVM и демон VDFS, а также есть ли файловая система root на хосте. Если чего-то из этого нет, то проверка показывает красный сигнал.
• Проверки File Server Health checks показывают, все ли в порядке с файловым сервером на отдельных хостах, и есть ли там файловая система root. Если что-то из этого не в порядке - показывается красный сигнал.
• Проверки Share Health отвечают за статус объектов файловых шар. Если служба протокола не работает для данного объекта, то показывается красный сигнал. Также могут быть оповещения для шар - и тогда будет желтый.

Для файловых шар SMB появился мониторинг производительности в интерфейсе vSAN UI. Можно смотреть за пропускной способностью (throughput), IOPS, задержками (latency) на уровне отдельной шары в реальном времени. Можно увеличивать временное окно просмотра для отдельных метрик. Также эти метрики доступны через API, поэтому такие продукты, как vRealize Operations также будут их использовать.

Доступную емкость SMB-хранилищ можно отслеживать через vSAN Capacity view:

Если вы нажмете на ссылку File shares overview в левом нижнем углу, то сможете открыть просмотр емкости на уровне отдельных шар. На картинке ниже представлен микс из SMB и NFS хранилищ, столбики в Usage/Quota показывают жесткие аппаратные квоты с цветовым кодированием заполненности:

Ну и напоследок небольшой обзор VMware vSAN File Services от VMware: